Done some testing with Module level Attr-DXL and discovered some nuances. Put the following in an Attr DXL named "dxlModuleInfo" that applies to both Objects and the Module as type 'Text'.
// test module level attribute with Attr-DXL
/* Put in a 'Text' attribute that applies to Module and Objects,
as an Attr-DXL
*/
Buffer buf = create()
string Name
AttrDef ad
int iLevel = level(obj)
//if (iLevel == 0) infoBox("start")
buf += "Identifier\t[" identifier(obj) "]\n"
buf += "Number \t[" number(obj) "]\n"
buf += "Level \t[" level(obj) "]\n"
if (iLevel == 0) obj."Object Text" = "Text"
//if (iLevel == 0) infoBox("before loop")
for ad in (current Module) do
{ if (!ad.object) continue
Name = ad.name
if (Name == attrDXLName) continue
// if (iLevel == 0) infoBox(Name)
buf += Name "\t[" (obj.Name) "]\n"
}
//if (iLevel == 0) infoBox("before Assign")
if (iLevel == 0) buf += "obj.AbsNo null: " (null obj."Absolute Number") "\n"
obj.attrDXLName = tempStringOf(buf)
delete(buf)
Then open a DXL window from the module and run the following to print the Module level value of the attribute.
Module mod = current
#include <utils/wipeattr.dxl> // Refresh DXL Attrs
print mod."dxlModuleInfo" "\n"
Attr__ attr = mod."Object Text"
if (null attr) //
then print "mod.Object Text is null\n"
else print (mod."Object Text") "\n"
I have the following observations:
> the best way to determine if your attr-DXL is running at the module level is to get the level(obj) and see if its zero.
> Object level attributes that are also Module level will display the correct information using obj.Name, even when "obj" is really the module.
> identifier(obj), number(obj), and level(obj) all seem to work.
> identifier(obj) seems to suggest that the Absolute Number is zero.
> Object level attributes that are not also Module level attributes are not undefined, but rather are defaulted to have null values, specifically including obj."Absolute Number"
> I see you can SET an Object level attribute for the module, in this case "Object Text". I find that VERY curious. Not sure why you would want to do this, however.
> I can determine no method of getting an "Object" handle on the module level without useing module-level attr-DXL. o=object(0) doesn't work.
> Attr-DXL that searches other attributes must be sure NOT to extract the value of itself, otherwise you go into an infinite loop and DOORS crashes within a few seconds. "if (Name == attrDXLName) continue" resolved that unpleasant experience.
> One prevents constant re-calculation of Attr-DXL by setting null results to a space instead of null: obj.attrDXLName = " ".
I make the following conclusions.
> bullet proof Attr-DXL needs to handle running at the module level
> few attr-DXL should be defined for the module.
> Its easy to crash and burn DOORS in this way.
> It may be easy to accidentally perform recursive queries which will crash DOORS. One way to avoid that is to put <obj.attrDXLName = " "> at the top of any DXL that does anything tricky. Then, if you query it again at least it has a value and isn't re-calculated.
Wonder what else there is to learn, such as what happens when you use Module Properties to query the value of a module-level attribute that is an Attr-DXL; perhaps that counts the number of objects in the module.
So far, the following looks like a reasonable standard start for AttrDXL:
if (null obj) halt // not Attr-DXL
if (level(obj) == 0) halt // Module level attr-DXL
// v9.2.0.1 bug, cannot set AttrDXL values of a deleted object. Fixed in v9.2.0.2
if ( isDeleted(obj) and
length(doorsInfo(infoVersion)) >=7 and
(doorsInfo(infoVersion))[0:6] == "9.2.0.1") halt
llandale - Tue Apr 19 09:56:58 EDT 2011 |
|
Re: Module Level AttrDXL
SystemAdmin - Tue Apr 19 18:53:23 EDT 2011
"Faskinating"!
I got lost with the "object text" bit though.
.....you can SET an Object level attribute for the module, in this case "Object Text"....
The GUI prevents any changes being made to System Attributes like "Object Text" - so how did you manage to alter the "Object Text" AttrDef to also be a module level attribute? I tried the following and it failed.
AttrDef ad = find(current Module, "Object Text")
print ad.name
ad = modify(ad, setModule, true)
//This fails with the message: Object Text-R-E- DXL: <Line:4> cannot modify system attribute Object Text
Paul Miller
Melbourne, Australia
|
|
Re: Module Level AttrDXL
Mathias Mamsch - Tue Apr 19 20:34:47 EDT 2011
So no news since the post one month ago? My hope was you would test the DXL ModuleProperties attribute thing ;-) Asking in the same direction as Paul: When you say you can set values to object attributes of the "Module" object, are they stored? Or is the assignment just ignored?
Regards, Mathias
|
|
Re: Module Level AttrDXL
llandale - Wed Apr 20 14:18:30 EDT 2011 SystemAdmin - Tue Apr 19 18:53:23 EDT 2011
"Faskinating"!
I got lost with the "object text" bit though.
.....you can SET an Object level attribute for the module, in this case "Object Text"....
The GUI prevents any changes being made to System Attributes like "Object Text" - so how did you manage to alter the "Object Text" AttrDef to also be a module level attribute? I tried the following and it failed.
AttrDef ad = find(current Module, "Object Text")
print ad.name
ad = modify(ad, setModule, true)
//This fails with the message: Object Text-R-E- DXL: <Line:4> cannot modify system attribute Object Text
Paul Miller
Melbourne, Australia
|
|
Re: Module Level AttrDXL
llandale - Wed Apr 20 14:25:23 EDT 2011 Mathias Mamsch - Tue Apr 19 20:34:47 EDT 2011
So no news since the post one month ago? My hope was you would test the DXL ModuleProperties attribute thing ;-) Asking in the same direction as Paul: When you say you can set values to object attributes of the "Module" object, are they stored? Or is the assignment just ignored?
Regards, Mathias
OK. Create Mod/Obj level DXL attribute "dxlMod1" containing this code:
if (level(obj) == 0) obj."Object Text" = "xxx"
Create another "dxlMod2" with this code:
if (level(obj) == 0) infoBox("Mod Text = " (obj."Object Text") "")
Run the following from the DXL interaction window:
Module mod = current
string s1 = mod."dxlMod1" // sets module Object Text
string s2 = mod."dxlMod2" // prints it OK
We see that we can indeed save the module level Object Text. We can only retrieve it from some other module attr-DXL however. It does not seem useful although it's curious.
So it indeed appears we need to protect ourselves, and Attr-DXL routinely needs something like this at the top:
if (level(obj) == 0) then halt // Running at module level which rarely makes sense.
|
|
Re: Module Level AttrDXL
Mathias Mamsch - Wed Apr 20 19:53:29 EDT 2011 llandale - Wed Apr 20 14:25:23 EDT 2011
Oops, found the post in my drafts as I prepared to write another post; forgot that it was already posted.
OK. Create Mod/Obj level DXL attribute "dxlMod1" containing this code:
if (level(obj) == 0) obj."Object Text" = "xxx"
Create another "dxlMod2" with this code:
if (level(obj) == 0) infoBox("Mod Text = " (obj."Object Text") "")
Run the following from the DXL interaction window:
Module mod = current
string s1 = mod."dxlMod1" // sets module Object Text
string s2 = mod."dxlMod2" // prints it OK
We see that we can indeed save the module level Object Text. We can only retrieve it from some other module attr-DXL however. It does not seem useful although it's curious.
So it indeed appears we need to protect ourselves, and Attr-DXL routinely needs something like this at the top:
if (level(obj) == 0) then halt // Running at module level which rarely makes sense.
Cool. I just tried setting access rights on the top level object node and see if they get inherited to the top level objects. And indeed, they DID! So DOORS showed me on the top level the modified inherited access rights, while on the module, the attributes,etc. all was normal.
Well I thought, nice, that now we can give a user "RM" rights on the module (meaning the right to open in exclusive edit, but not create attributes, etc), and still give him "RMCDA" rights on the object zero node, meaning he would be able to, setup shared edit for his module without Admin rights on the module or create top level objects even though he cannot create attributes or baselines ...
Unfortunately, when I tried opening the module with the newly priviledged user the Module Access Rights (not the top level node rights) were again inherited over the objects. It seems the access rights on the top level node are not saved, but always set back to inherit. So yeah the top level object node really seems pretty useless.
Regards, Mathias
This is what I tried from an attribute DXL:
if (level obj == 0) {
print "Setting access!\n"
specific obj
set (obj, read | modify | control | delete , "MyUser")
}
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: Module Level AttrDXL
llandale - Wed Apr 20 20:38:34 EDT 2011 Mathias Mamsch - Wed Apr 20 19:53:29 EDT 2011
Cool. I just tried setting access rights on the top level object node and see if they get inherited to the top level objects. And indeed, they DID! So DOORS showed me on the top level the modified inherited access rights, while on the module, the attributes,etc. all was normal.
Well I thought, nice, that now we can give a user "RM" rights on the module (meaning the right to open in exclusive edit, but not create attributes, etc), and still give him "RMCDA" rights on the object zero node, meaning he would be able to, setup shared edit for his module without Admin rights on the module or create top level objects even though he cannot create attributes or baselines ...
Unfortunately, when I tried opening the module with the newly priviledged user the Module Access Rights (not the top level node rights) were again inherited over the objects. It seems the access rights on the top level node are not saved, but always set back to inherit. So yeah the top level object node really seems pretty useless.
Regards, Mathias
This is what I tried from an attribute DXL:
if (level obj == 0) {
print "Setting access!\n"
specific obj
set (obj, read | modify | control | delete , "MyUser")
}
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
Holes holes holes. Recall v4 and the invisible 'Users' module; you could not query the user's "Password" attribute, but you could browse History to see what it was changed to.
|
|
Re: Module Level AttrDXL
Mathias Mamsch - Thu Apr 21 06:08:20 EDT 2011 llandale - Wed Apr 20 20:38:34 EDT 2011
Even if you provided access to "Prefix" in this manner, you would not be able to do this: obj."Prefix" = "ABC_", since its not an object attribute. It would not surprise me that the top level object is indeed an object and is not in fact the Module. That is obj."Last Modified On" "" != mod."Last Modified On" "". Does seem useless, ... unless you need a place to store otherwise secret stuff ... like self modifying triggers.
Holes holes holes. Recall v4 and the invisible 'Users' module; you could not query the user's "Password" attribute, but you could browse History to see what it was changed to.
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: Module Level AttrDXL
llandale - Thu Apr 21 10:08:51 EDT 2011 Mathias Mamsch - Wed Apr 20 19:53:29 EDT 2011
Cool. I just tried setting access rights on the top level object node and see if they get inherited to the top level objects. And indeed, they DID! So DOORS showed me on the top level the modified inherited access rights, while on the module, the attributes,etc. all was normal.
Well I thought, nice, that now we can give a user "RM" rights on the module (meaning the right to open in exclusive edit, but not create attributes, etc), and still give him "RMCDA" rights on the object zero node, meaning he would be able to, setup shared edit for his module without Admin rights on the module or create top level objects even though he cannot create attributes or baselines ...
Unfortunately, when I tried opening the module with the newly priviledged user the Module Access Rights (not the top level node rights) were again inherited over the objects. It seems the access rights on the top level node are not saved, but always set back to inherit. So yeah the top level object node really seems pretty useless.
Regards, Mathias
This is what I tried from an attribute DXL:
if (level obj == 0) {
print "Setting access!\n"
specific obj
set (obj, read | modify | control | delete , "MyUser")
}
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
This is going to nag at me for a while, probably as long as it takes IBM to realize their mistake and get rid of that object.
|
|